\section*{Design}
\subsection*{Developer View}
Our system \see{fig:design-overall} is composed of four main parts:
\vspace{-5pt}
\begin{itemize*}
\item the Android app used by drivers,
\item the Postgres database storing all user/specimen data,
\item the web platform for entering/altering/viewing data in the
  system,
\item and the Android server which keep the server application data
  consistent with what the drivers see.
\end{itemize*}

This gives our system two main user interfaces: the Android app and
the web platform.  The web platform \see{fig:design-web} is for
viewing and entering data from clients and lab personnel into the
database through a database handler \see{fig:design-db-handler} which
then works directly with a lower-level database interface
\see{fig:design-database}. All web interactions with the internal
system components will be facilitated by the web server thread
\see{fig:design-web-server}. Meanwhile, the Android app
\see{fig:design-android} is soley for drivers while they are in
transit.  The app will communicate with the Android server
\see{fig:design-android-server} and then likewise through the database
handler.  This allows for the database handler to be a central
event-driven point that will update and drivers as all information
passes through it on the way to the database.


\subsection*{Customer View}
For a customer, our system \see{fig:design-customer} is very simple.
There will be one Android app per driver and one consolidated web
interface for client and admin alike.

For a lab worker, the web interface \see{fig:design-web} will ask for
login credentials and then trasfer them to lab viewing screen.  This
will be composed of a listing of all tracked specimens as well as
statistical information pertaining to loads per hour and rough ETAs.

For an admin user, the web interface will log a user into another
screen that allows for full control over client user privliges as well
as driver information. The driver information consists of routing
information, location checklists, and starting/ending shift checklists
(please see SRS documents for more information).

A client user will be treated to much the same web interface as a lab
worker except their view will be localized to their own tracked
specimen.  Also, a client can enter information for new specimen
packages to be sent to a lab here \see{fig:design-add-use-case}.  It
will then be sent to an available driver's routing information
automatically when possible.

Finally, a driver's Android platform application will be used by them
to systematically go through each step necessary to complete their
assigned routes.  Just by checking each item on their lists and
scanning in the barcodes on packages when picking them or dropping
them off at locations \see{fig:design-scan-use-case}, the web
interfaces will be automatically refreshed.

\subsection*{Alternatives}
One alternative design was to take out our core database handler
(Andrew's module) and instead facilitate our event-handling directly
in the same interface as that handling SQL queries.  We went away from
this so that we could improve our system cohesion by correctly
absracting these two separate pieces of behavior.  Also, our current
design allowed for the web server and Android server to have nothing
to do with each other, communicating instead through the core handler
only if necessary.  If we didn't have the core handler, we would have
much more coupling between these two modules and it make developing
them separately a pain.

Another alternative design was to have the web server do the majority
of the work and manage the database and handle communications with the
mobile devices.  This is something akin to having a Ruby on Rails
application.  This design cuts down on the number of components and
layers of abstraction but makes changing and division of work much
more complicated so it was abandoned for the current system.  It would
have worked either way, but then we would have had to mostl likely
change our toolset from Java to solely a scripting language like Ruby
or Python.  This was felt to be a bad decision since most of our team
doesn't have strong experience with these types of languages as
opposed to our well-versed Java minds.

Finally, our design clearly makes distinctions between HTML code and
web server (Clojure) code by separating them into entirely different
files/directories.  This is opposed to many current web frameworks
like Rails/Django but we felt that this would allow those two pieces
-- the web server and the web platform -- to be decoupled enough to be
worked on fairly independently of each other.  This was felt to be
very desirable for our small-scale team on a short release schedule.

\subsection*{Assumptions} 
We have assumed for our design that we (and our customers) have access
to Android platform (version 1.5 or better) devices.  Also, we have
assumed that the core handler will be a significant enough module for
it to have a full-time member devoted to it.  That way, we have 6
distinct module responsibilities for our 6 team members.
